A Reference Version of HOL

The second author has implemented a reference version of the HOL logic (henceforth called gtt). This version, written in Standard ML, is as simple as possible, making as few assumptions as necessary to present the essence of HOL. This simplicity makes the implementation easy to understand, to port, to develop, to change, and to informally reason about. The first author has ported gtt to another dialect of ML, and developed the parsing, prettyprinting, and typechecking support needed to take gtt beyond its initial rudimentary conception. The implementation of gtt has already been of use in developing a variant of the HOL logic. As of this writing, there are at least four or five extant implementations of the HOL logic. These have been intensively developed, in some cases over decades, which leads us to an overwhelming question: why another? In particular, why gtt? There are several answers to this, stemming from different desires and needs in the HOL community. Changing the logic a little bit. Some authors [Mel92, Bou92, Sli92, Gun91] have recently proposed extensions or alterations to the HOL logic. Such modifications are difficult to implement in HOL88 because such fundamental changes need to be performed in the “sea of Lisp” that underlies HOL88. Such alterations are much easier to do in hol90 because it is a far better structured system that is furthermore written all in one language; still, some aspects of the core of the hol90 implementation are difficult to modify. The gtt implementation provides a particularly simple setting to prototype changes that might eventually migrate into a real implementation of HOL. Later in this paper we give an overview of one such development. Changing the logic a lot. Another conceivable use stems from noticing how small and simple the primitive inference rules are, given the prelogic. Someone who wanted to implement a logic other than HOL on top of a lambda calculus with ML-style polymorphic types could use the gtt prelogic as an ‘implementation-springboard’. Although logical frameworks such as Isabelle would seem to have cornered the market in this area, the gtt style of implementation offers finer control, and this can be useful in situations where the object logic embeds awkwardly into the logical framework. For example, a dependent type theory is difficult to model effectively in Isabelle, since one would want to directly use the contexts of Isabelle to implement the contexts of the object logic; however, an Isabelle context is basically a set (of lambda terms), and that is too simple to capture some aspects of type theory contexts. Alternatively, one could build a faithful type theory implementation directly on top of the gtt prelogic. This example suggests that, for the purposes of quickly implementing a logic, perhaps the issue of whether inference rules are lambda terms or ML programs is less important than the provision of an expressive prelogic plus general tools such as extensible parsers and pretty printers, parameterized rewriting engines, and other specializable reasoning tools. For discussion of these issues from a somewhat different perspective, see [CH90]. Exploring important implementation issues. One interesting research field is the investigation of representations of the lambda calculus for theorem provers (some of the choices are explored in [Hue89]). As one example of the tradeoffs to be considered, de Bruijn terms simplify substitution and allow quick tests of alpha-equivalence; however, they also generate more garbage, since the breaking apart of a lambda abstraction involves a full term traversal to replace the bound variable with a free variable. Here the benefit of gtt’s simplicity is that changes to the implementation can be more easily effected since the scope of such changes is smaller. Also there is the methodological point that different approaches can be more easily compared in such a simple setting. The downside of gtt currently is that is not a large body of examples for evaluating such changes and deciding whether they ought to be propagated to a real implementation. However, such changes, if they work in the reference version, are probably simple to propagate to a cleanly written real implementation. Portability. Although there are several good implementations of Standard ML available, the compiler technology for this language has not yet developed to the point that reliable ports to new architectures can be achieved in a timely fashion. Spread of the many formal methods tools that have sprung up around ML is thus impeded. Furthermore, the size of a real HOL system is a genuine problem in making HOL-based verification tools widely available. Not everybody can afford a high-powered workstation (or equally importantly, the memory) to run HOL on. Therefore, a simple but perhaps limited version of HOL that is easily portable to ‘ML-like’ languages might help increase the HOL user base. Teaching. gtt is a concrete, graspable, and executable answer to the question “what is an implementation of HOL”? Possibly gtt can be of use to those wishing to teach aspects of higher-order logic and theorem proving. Another use would be to provide an executable introduction to the essence and structure of LCF implementations in general (like [Gor82]), and the hol90 implementation in particular. An analogous development for the Calculus of Constructions can be found in [Hue89].